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UETBOD USD &PPABATDS FOR USIHQ BUSIUBSS ROLES OR 



USER ROZ£S FOR eBLECXXBG POR2CLE7S IN & WEB SOKIAli 



Field o£ the iBventian 

This invention relates to the Internet, more particularly to methods 
and apparatus for producing and using portals and portlets in web 
applications to provide enhanced capabilities for web sites. 

Baokaround o£ the Invention 

The World Wide Web brought a paradigm shift to communications over 
the Internet, conveying graphical information to users. With the advent of 
the Web there was and still is demand for increasing communicability and 
broad connectivity. 

The Portal (previously known as a web portal) has brought a paradigm 
shift in internet space. A web site that offers an array of resources or 
services such as 'email, forums, searOh engines, databases or other- 
information may be considered to be a portal. The first web portals may 
have been online services. For the first time, users surfing this 
internet were able to see web pages that were assembled with and offered 
information coming from various sites in the world wide web, yet the 
aggregation's constitution was transpsurent to the user. A user making use 
of a typical web browser sees a cohesive web page displayed. The 
origination of different parts of the page from various internet sites not 
associated with the web site being viewed is not readily apparent. These 
parts are termed Portlets. 

Portiets are the visible active components end users see within 
their portal pages. Similar to a window in a PC desktop, each portlet 
"owns" a portion of the browser or Personal Digital Appliance screen where 
it displays results. 

From a user's view, a portlet is a content channel or application to 
which a user subscribes, adds to their personal portal page, and 
configures to show personalized content. 

From content providers' view, a portlet is a means to make available 
their content. 
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From a portal a<3ministrator's view, a portlet is a content container 
that can be registered with the portal, so that users may subscribe to it. 

From a portal ' s point o£ view, a portlet is a component rendered 
into one of its pages. 

From a technical point of view, a portlet is a piece of code or a 
small application that runs on a portal server and provides content that 
is to be embedded into portal pages. In the simplest terms, a portlet. may 
be a Java™ servlet that operates inside a portal. 

Each part {portlet) of a given page (typically sourced from 
different places in the world wide web) can collaborate with another part 
(portlet) of the same page to achieve higher function for a user surfing 
or accessing the page. Thus, a portal becomes the single point of access 
for multiple users, via multiple channels, to multiple soirrces of 
information. 

Portals can be applied in vcurious business models, namely: business* 
to consumer, business to business, or business to enterprise. The key to - 
quick adoption of the portal paradigm ties strongly to its ability to 
integrate existing web application data into the portal framework in a 
seamless fashion. 

However, various technical hurdles still exist for such seamless web 
application integration into portal. 

Hhere are limitations in the prior art concerning how the following 
- portal artifacts work together with- existing web applications. The 
implementation of integration of web applications into portal architecture 
is not well defined. These entities include: 

Original http request to a portal; 

A portlet session within a portal; 

A http request from the portal to the pertinent web application. 

When different users access a portal page, the original http request 
for each user is directed towards the portal server (a) . The original http 
session for each user is also entirely ""owned" the portal server. Each 
of the portlets has its own independent session called a portlet session. 
When a portlet needs to render information that comes from a given web 
application, (b) , there are typically the following technical hurdles: 
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i. There is no existing mechanism for a portlet to generate http 
requests and responses to and from the backend web 
application. 

j. lliere is no existing mechanism to manage imiltiple requests and 
responses to a calling portlet {and the portlet session) 
mapping correctly with multiple requests euad responses to a 
backend web application (and the web application's session). 
Bach (both portlet and web application) maintains its user 
session accordingly. 

This gets complicated when multiple portlets call the same web 
application, with the web application treating these multiple portlets 
requests within the same web application session. 

k. •Hhere is no existing mechanism to relay session information 
between the multiple portlet sessions and the web 
application's session. 

When a well defined set. of portlets within the same portlet 
application interact with the one web application at the backend, all the 
participating portlets must be' able to retrieve and forward the correct 
^ session information to the web application at the backend such that the 
information rendered from the web application is consistent with the , 
setting of that of thte portal of the portlets. Exantples of such setting 
'includes locale information, user agent of that particular access etc. For 
example, the responses sent from the web application must be using the 
same locale with the portlet in the portal server who displays it. 

There is no existing mechanism for single sign on such that- the 
portal user's credentials will not be challenged by the backend web 
application. This is a critical requirement. The absence of it will result 
in the user's credentials being challenged when the user moves from one 
part of a web page to a different part of the same web page; as the 
portlets have different originations and identification requirements. 

There is no existing mechanism for synchronization of multiple 
requests or responses between portlets of a given portlet application and 
the pertinent web application backend. 

The prior art has limitations concerning how multiple portlets 
within the same portlet application can collaborate with one another 
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(sharing the same context) as well as with the various integrated web 
applications dynandcally is not defined. 

One Usage Scenario involving multiple portlets collaborating by 
sharing the same 'context' dynamically will serve to conceptually 
illustrate the limitation: 

With three portlets being displayed on the same portal web page: 

- one portlet shows the account summary by displaying a list of 
accounts 

- the second portlet shows a given account's list of outstanding 

invoices 

- the third portlet shows a given account's order history summary 

The second and the third portlets are contextually bound to the 
first portlet dynamically, reflecting outstanding invoices (2™* portlet) 
and order history (3"* portlet) and are synchronized with an account 
selected from the account list of the first portlet. 

Limitations of the prior art: 

i. No mechanism exists to define a sub-grouping of portlets within a 
portlet application that would work collaboratively. 

j . No mechanism exists to define a context (that can be dynamically 
changed) shared among this sub-group of portlets within a given 
portlet application: example of context here is the selected account 
in portlet 1, such account selection can be changed dynamically. 

k. No mechanism exists to detect the change in context dynamically: 
example of the chajtige of selection from one acco\mt to another 
account from the acco\mt list in portlet 1 of the above example. 

1. No mechanism exists to register a predefined action (or responses) 
for each participating portlets within the sub-group of portlets 
that share the same context: exan^le of displaying the list of 
outstanding invoices (action in portlet 2) when the context is 
changed (from one account selection to another in portlet 1) . 



m. No mechanism exists to relay that dynamic context to the relevant 
integrated web applications 
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There is no mechanism existing in the prior art to define a refresh 
sequence for a group of port lets within a portlet application 

i. There is no provision today for a portal designer to specify the 
refresh order of a given set of portlets being displayed. 

In our scenario above, the portal designer would want to have the 
first portlet (account list) refreshed first, the second portlet refreshed" 
second etc. so that the 2°^ and the 3'" portlets automatically have. Defined 
actions (when the portlet is deployed) taking place in a correct sequence. 

There is a lack of a well defined mechanism in portal architecture 
to support the aggregation of portlets based on business rule and user 
profiling information including the users ^' role. 

i. There is no existing mechanism to define aggregation of portal 
resources per user based on business rules. 

Example: all teenage- portal users see one group of portlets, all 
senior portal users see another group of portlets. 

. j . There is no existing mechanism for such rule based and user based 
aggregation of portlets that is performed dynamically at runtime. 

There is no sharing of portal level business rules and user profile 
information with pertinent integrated back end web applications. 

There is no sharing of business rules or user segmentation 
information with an integrated web application such that these rules and 
user segmentation can be consistent across a portal and its integrated 
backend web application. For example, if there is a rule defining the age 
range of a teenager, such a rule should be visible and applicable to the ' 
integrated web application for consistency. 

Terminology 
Portlets 

Portlets are the visible active conponents that the end users see 
within their portal web pages. Similar to a window in a PC desktop, each 
portlet "owns" a portion of the browser or PDA (Personal Digital 
Appliemce) screen where it displays portlet specific information. 
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Portlet application 

Portleta can also be grouped together in a portlet application. 
Portlet applications are distributed and deployed using Web archive files 
(WAR) . There are portlet specific extensions to the standard Web 
application deployment descriptor. 

Portlet KteBsages 

Portlet messages are used for the communication between two portlets 
using portlet actions and portlet messages. "The sending portlet creates a 
portlet action, encodes the action into a URL. When the XJRL is addressed, 
e.g. by a user trying to accomplish an task, the action listener is called 
and sends a portlet message to send the necessary data. 

jPoji^let Session 

A Portlet session is created for each portlet instance for each user 
logging on to maintain session information for each user per portlet 
instance. 

Portals today do not have well defined mechanisms to support the 
aggregation of portal resources per user based on business rules as well 
as user profiling information including users' business role.' There is 
also no existing mechcuaism for such rule based cuid user based aggregation 
of portal resources that can take place dynamically at run time. 

Summary of the Invention 

The various embodiments of the invention herein address one or more 
-shortcomings of the prior axt. 

This invention provides the appEuratus for dynamically displaying 
portal resources based on accessing rules from a rules database, including 
rules controlling display of sets of portlets, pages, page groups to 
users. 

An embodiment of the invention includes means to select portal 
resources (portlets, page and page groups) as displayed to a user based on 
pluggable rules engine; a rules database; and a portlet application 
aggregation engine which applies rules to select and display selected 
portlets, pages and page groups to a user. 
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toother embocliment of the invention includes means to access roles 
using a roles database which contains rules controlling display of portal . 
resources based on user roles. 

An embodiment o£ the invention enables a fine level of 
personalization with dynaioic capabilities for rendering portal resources 
based on rules. 

One embodiment of the invention provides appsuratus for displaying to 
a user a web portal for a web application, the web portal displaying a 
plurality of associated portlets, sharing information with each other, 
accessible by the user; including: a portal server for operating a web 
portal to pro^?ide access to the web application; a portlet application for- 
operating on the portal server, for managing a collection of associated 
portlets; the portlet application includes: means to initiate portlets on 
requests of a user to access the web application; means to manage a 
portlet application session object for the portlets; and, a portlet 
application session object data store controlled by the portlet 
application session object for saving parameters from user requests for. . 
associating the portlets with the with the portlet application session 
object. 

The apparatus of the invention may. include a portlet application . 
communication client in the portlet- application for comnctunicating between 
the portlet application session object and the web application to convey 
■user requests received from the associated portlets to the web 
application. The portlet application may assign a common key to each 
portlet associated with a portlet application seisslon object. 

Another embodiment of the invention provides an apparatus for 
displaying a web portal for a web application to a plurality of users, 
the web portal displaying a plurality of portlets, sharing Information, 
accessible by the users; including: a portal server for operating a web 
portal to provide access to the web application; a portlet application for 
operating on the portal server for each of the plurality of users, for 
managing a collection of associated portlets for each of the plurality of 
users; each the portlet application includes: meeins to initiate portlets 
on requests of one of the plurality of users to access the web 
application; means to manage a portlet application session object for the 
portlets; and, a portlet application session object data store controlled 
by the portlet application session object for saving parameters from user 



wo 2004/031986 



'CT/GB2003/004244 



8 

requests for eissociating the portlets with the with the portlet 
application session object. 

Another embodiment of the invention provides appauratus for 
displaying to a user a web portal for a pl\irality of web applications, the 
web portal displaying a plurality of associated portlets, sharing 
information with each other, accessible by the user; including: a portal 
server for operating a web portal to provide access to the web 
application; a plurality of portlet applications relating respectively to 
the plvirality of web applications for operating on the portal server, each 
portlet application being adapted to managing a collection of associated 
portlets; each the portlet application includes: means to initiate 
portlets on requests of a user to access one of the plurality of web 
application; means to manage a portlet application session object for the 
portlets; and, a portlet application session object data store controlled 
by the portlet application session object for saving parameters from user 
requests for associating the portlets of the portlet application with the 
with the portlet application session object. of the portlet application 
session. 

Another aspect of the apparatus of the invention includes a user 
session information table adapted to connect to multiple web applications 
with the portlet application session object. 

Still another eiribodiment of the invention provides apparatus for 
displaying to a user a web portal for a web application, the web portal 
displaying a plurality of associated portlets, sharing information with . 
each other, accessible by the user; including: a portal server for 
operating a web portal to provide access to the web application; a portlet 
application for operating on the portal server, for managing a collection 
of associated portlets; the portlet application including: means to 
initiate a first portlet on request of a user to access the web 
application; means to create a portlet application session object for the 
user for the first portlet ; means to save pcurameters from the request ; . 
means to generate additional portlets associated with the first portlet 
on further requests of the user to access the web application; a portlet 
application session object data store controlled by the portlet 
application session object for using the saved parameters for associating 
the additional portlets with the with the portlet application session 
object; and, means to create a portlet application communication client 
(httpClient) for communicating with the portlet application session object 
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and the web application to convey user requests received from the first 
and additional portlets to the web application. 

The apparatus may include a portlet application comnvunication client 
in the portlet application for communicating between the portlet 
application session object and the web application to conv^ user requests 
received from the associated portlets to the web application. 

The portlet application preferably assigns a common key to each 
portlet associated with a portlet application session object. 

A user session information table adapted to connect to multiple web 
applications with the portlet supplication session object may 
advantageously be provided. 

Another embodiment of the invention provides apparatus for 
displaying to a user a web portal for a web application, the web portal 
displaying a plurality of associated portlets, sharing information" with, 
each other, accessible by the user; including: a portal server operating a 
web portal to provide access' to the web application; a, portlet application 
operating on the portal server, for managing a collection of associated 
portlets; the portlet application including: means to initiaite portlets on 
requests of a user to . access the web application; means to manage a 
portlet application session object for the portlets; and, a portlet 
application session object data store controlled by the portlet 
application session object for saving parameters from user requests for 
associating the portlets with the with the portlet application session 
object. 

Another aspect of the invention provides a method of sharing 
information between a plurality of associated portlets in a web portal 
including: granting access for each of the plurality of associated 
portlets to a portlet data store; permitting each of the pl\irality of 
associated portlets to write data to the portlet data store and to read 
stored data from the portlet data store. 

The method above may advantageously provide a system wherein the - 
associated portlets are managed by a portlet application adapted to 
operate on a data processing system; wherein the portlet data store 
comprises portlet application storage managed by a portlet application 
session object which controls reading and writing of data by the 
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associated portlets in the data store permitting exchange of data among 
the associated portlets of the port let application. 

Another aspect of the invention provides appaxatus for sharing 
information between multiple associated portlets in a web portal 
including: a portlet application for managing the multiple associated 
portlets; a portlet application data store; means for granting read/write 
access to the data store by the multiple associate portlets to enable the 
portlets to exchange data among each other. 

Yet another aspect of the invention provides a portlet (application) 
server capable of operating on a portal server for hosting multiple 
associated portlets in a web portal including: means for managing the 
multiple associated portlets; means for managing a portlet application 
session object; a portlet application data store managed by the portlet 
application session object for granting read/write access to the data 
store to the multiple associate portlets t6 enable the associated portlets 
to excliange data among each other. 

Another aspect of the invention provides a portlet (application) 
server capable of operating on a portal server for hosting multiple 
associated portlets in a web portal including: means for managing the 
multiple associated portlets; means for creating and managing a portlet 
application session object; a portlet application data store created and 
managed by the portlet application session object for granting read/write 
access to the data store to the multiple associate portlets to enable the ' 
associated portlets to exchange data among each other. 

Advantageously/ the portlet application assigns a common key to each 
portlet associated with a portlet application session object. 

Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, including: portlet 
application means for managing the multiple associated portlets; portlet 
application means for managing a portlet application session object for 
the user; portlet application means for granting the key to each 
associated portlet for controlling access to the portlet application 
object. 

Still another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
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portlets in a web portal accessible by a user, including: portlet 
application means for meuiaging the multiple eissoclated portlets; portlet 
application means for creating and managing a portlet application session 
object for the user; portlet application means for creating and managing a 
key for the user for the portlet application session object? portlet 
application means for granting the key to each associated portlet for 
controlling access to the portlet application object. 

Advantageously one portlet application is assigned to each user and 
one key is assigned respectively for each user to respective portlet 
application objects for each portlet application. 

Another aspect of the invention provides apparatus for displaying to 
a user a web portal for a web application including: a portal server for 
operating a web portal to provide access to the web application by a user; 
a portlet application, for managing a- collection of associated portlets', 
for operating on the portal server; a portlet application session object 
for the user for the associated portlets; a portlet application session 
object data store controlled by the portlet application session object; a 
portlet application communication client linked to the portlet application 
data store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the communication client having a request buffer 
for storing and synchronizing requests from the associated portlets to 
enable the comnainication client to generate synchronized ' to the web 
application. 

Preferably the. portlet application communication client is adapt.ed 
to send information including requests over a network to a web application 
and receive information including responses to the requests from the web 
application. 

Another aspect of the invention provides apparatus for displaying' to 
a user a web portal for a web application including: a portal server for 
operating a web portal to provide access to the web application hy a user; • 
a portlet application, for managing a collection of associated portlets, 
for operating on the portal server; a portlet application session object 
for the user for the associated portlets; a portlet application session 
object data store controlled by the portlet application session object; a 
portlet application coimraanication client linked to the portlet application 
data store for communicating between the associated portlets cuid the web 
application to convey user rec[uests received from the associated portlets 
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to the web application; the coitmunication client having a request buffer 
for storing and serializing requests from the associated portlets to 
enable the coromunication client to generate serialized to the web 
application. 

Preferably, the portlet application communication client is adapted 
to send information including requests over a network to a web application 
or web application server and receive infomation including responses to 
the requests from the web application. 

Another aspect of the invention for a portal server adapted to 
operate a web portal to provide access to a web application; having a 
portlet application operating on the portal server, for managing a 
collection of associated portlets; wherein the portlet application 
includes: means to initiate portlets on requests of a user to access the . 
web application; means to manage a portlet application session object for 
the portlets; and, a portlet application session object data store 
controlled by the portlet application session object for saving parameters 
from user requests for associating the portlets with the with the portlet 
application session object, the apparatus including: a portlet application 
communication client (httpClient) linked to the portlet application data 
store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the portlet application communication client 
having a user session information store (mapping table) for storing user 
session information including selected information from the set of the 
following user session information: user id, user credentials, language 
preferences, session timeout information, session id, etc. for mapping the 

user session Information to a corresponding session of the web 

application. 

The session timeout information preferably includes session timeout 
information of the portal server and the web application. 

Another aspect of the invention provides portlet application, for 
maixaglng a collection of associated portlets in a portal, for operating on 
a server providing access to a web application by a user; the associated 
portlets having portlet request peurameter maps storing data and 
instructions from user requests to the portlets; a portlet aj^lication 
session object for the user for the associated portlets; a portlet 
application session data store controlled by the portlet application 
session object; a portlet application communication client (httpClient) 
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linked to the portlet application data store for comnrunicating between the 
associated portlets and the web application to convey user requests 
received from the associated portlets to the web application; the 
connnunication client having a request buffer for storing requests from 
portlet request pcirameter maps of the associated portlets to enable the 
communication client to provide data and instructions for the web 
application. 

Another aspect of the invention provides a portlet application 
communication client (httpClient) linked to the portlet application data 
store for communicating between the associated portlets and the web 
application to convey user requests received from the associated portlets 
to the web application; the portlet application communication client 
having a us%r' session information store (mapping table) for storing user 
session information including selected information from the set of the 
following user session information: user id, user credeiti8LlB, language 
preferences, session timeout information, session id, etc. for mapping the 
user session information to a corresponding session of the web 
application; the session timeout information including session timeout 
information of the portal server and the we application. 

Preferably the above includes synchronization means for the portlet 
application commxinication client for matching session timeouts between 
portal server and the web application by re-authenticating the user if the 
web application times out before the portal server.' 

Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, the portal server providing 
messaging means for allowing the associated portlets to message each 
other, including: portlet application means for managing the multiple 
associated portlets; each associated portlet having a portlet descriptor 
describing context names; the associated portlets including collaboration 
groups of portlets having corresponding context names defining context 
values; each the group of portlets including a master portlet and at least 
one slave portlet; wherein each the group of portlets share context names 
in common; means in the portal server for broadcasting communicating 
changes in context values of a master portlet to slave portlets of the 
master portlet; means in the portal server for changing context values of 
the slave portlets to match context values of the master portlet as 
broadcast . 
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Another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, the portal server having 
portlet refresh capability, including: portlet application means for 
managing the multiple associated portlets; each associated portlet having 
a portlet descriptor; each portlet descriptor including refresh priority 
description for the portlet; the associated portlets including 
collaboration groups of portlets; each the group of portlets including a 
master portlet and at least one slave portlet; means in the portlet 
application means for refreshing the portlets in order of their refresh 
priorities . 

Still another aspect of the invention provides a portlet application 
capable of operating on a portal server for hosting multiple associated 
portlets in a web portal accessible by a user, the portal server having . 
portlet refresh capability, including: the associated portlets including 
collaboration groups of portlets; portlet application means for managing 
the multiple associated portlets; each associated portlet having a portlet 
descriptor; each portlet descriptor including a refresh priority 
description for the portlet, and a refresh, description priority for the 
group of portlets of which the portlet is a member; each the group of 
portlets including a master portlet and at least one slave portlet; means ' 
in the portlet application means for refreshing the portlets in order of 
their priorities; means in the portlet application means for refreshing 
■ the collaborative groups of portlets in order of their group refresh 
priorities. 

The master portlets have higher priorities than slave portlets. 

Preferably the portlet application refreshes the groups first in 
group priority order and then refreshes within each group in priority 
order. 

Another aspect of the invention provides apparatus for displaying to 
a user a web page session for a web application, the web page session 
displaying a plurality of associated collaborative portlets, sharing 
information with each other, accessible by the user including: a portal 
server for operating a web portal to provide access to the 
application; a portlet application, for managing a collection of 
associated portlets, for operating on the portal server; access means' to 
access a rules dateJsase; the rules including rules controlling display of 
sets of portlets, pages, page groups to users; selection means to select 
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a set of portlets, pages, and page groups to be displayed to a user based 
on infoxnatlon provided by the user (information properties) . 

In another variation of the invention the selection means includes a 
pluggable rules engine, a rules database, and a portlet application 
aggregation engine which applies rules to select and display selected 
portlets, pages, and page groups to a user. 

Another aspect o£ the invention provides apparatus for displaying to 
a user a web page session for a web application, the web page session 
displaying a plurality of associated collaborative portlets, sharing 
infozmation with each other, accessible by the user including: a portal 
server for operating a web portal to provide access to the web 
application; a portlet application, for managing a collection of 
associated portlets, for operating on the portal server; roles access 
means to access a roles database; the roles database containing rules 
controlling display of sets of portlets, pages, page groups to users based 
on user roles; role selection means to select a set of portlets, pages, 
and page groups to be displayed to a user based on eui identified role of 
the user. . 

Other aspects of the invention provide an article including : a 
computer readable signal bearing medium; computer program code means 
recorded on the medium adapted to perform the methods of the embodiments 
of the invention described above. 

Other aspects of the invention- provide an eurticle including: a 
coit^uter readable signal beeiring medium; computer program code means 
recorded on the medium adapted to inclement the apparatus of any of the ■ 
embodiments of the invention described above. 

The medium may be selected from the group consisting of magnetic, 
optical, biological, and atomic data storage media as appropriate. 

^e mediiun may be a modulated carrier signal.' 

The signal may be a transmission over a network. 

BriQ£ peseription of the PrawliMra 

Embodiments of the present invention will be described by way of-- 
exanple, referring to the accompeuiying drawings in which: 
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Figure 1 depicts a Dynamic Context Chaining Model; 
Figure 2 depicts a Web Application Integration With Portal; 
Figure 3 depicts an Integration Structural Diagram; 
Figure 4 depicts an integration Flow Diagram; 

Figure 5 depicts a Structure Diagram for Portal integration with Web 
Application; 

Figure 6 depicts a Flow Chart for Integration; 

Figure 7 depicts an Example Of Dynamic Context Groups for Portlets; 

Figure 8 depicts a Portlet Application Initialization For Dynamic 
Context As Specified In the definition instance; 

Figure 9 depicts a Dynamic Context Portlet Group Run Time Flow; 

Figxire 10 depicts a Role Based Dynamic Aggregation Component 
Structure Map; 

Figure 11 depicts a Rule Based Dynamic Aggregation Congponent Flow 

Map; 

Figure 12 depicts a Role Based Dynamic Aggregation Flow Chart; 
Figure 13 depicts the heindling of portlets requests to web 
applications; . ■ .- * 

Figure 14 depicts a sync model diagram; 

Figure 15 depicts a flow chart for a' sequence aware portal 
aggregation engine; 

Figure 16 depicts the defining of a dynainic group called "MaleTeen" 
and assigning users to the group; 

Figure 17 depicts the assigning a rules database content group 
selection action to a dynamic user group; and, 

Figure 18 depicts the creation of a new action called 
'maleTeenAction* . 

Detailed Deserlption o£ Prefeawed Ep Kw^jwaw fcB c£ the Invention 

This section describes preferred embodiments of the invention. 

A.l. Bortal and Web Applications Integration Enablensnt 

Figure 2 illustrates a preferred embodiment of the invention 
illustrating its use with a web portal server. 

A. 1.1 Portlet i^plioation bttp olient 

The portlet (that makes http requests to the back end web 
application) uses the Portlet Application Http client 209 used to open an 
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Http connection to a backend web application that runs on a backend 
application server 210. The backend web application requires a Portlet 
^plication Http client 209 to provide session support over multiple 
requests and responses, cookie handling and Single Sign on (SSO) logic. 
All the portlets in the same portlet application use the same portlet 
application Http client object 209 to connect to one or more backend web 
applications. There is one Portlet Application http client 209 per portlet 
application 204. 

A. 1.2 Portlet Application Session 

The Portlet Application Session object 208 is a unified data store 
object that can be shared by all portlets in a given portlet application. 
This object exists per user and per portlet application. The Portlet 
Application Session object 208 provides infrastructure so that multiple 
portlets in a given ^ portlet application will have independent user 
sessions (called portlet sessions 204 205,206) but share the same Portlet 
Application Session, and coniraunicate with the web application on the 
backend application server 210 with a single web application session. 

A. 1.3 Portlet applioation session eoateacb 

Portlet Application Session Context provides information that is per 
uiser and per portlet application. This .means that all portlets within the 
same portlet application (204, 203) can now have a way to share common 
information among them. 

A, 1.4 Session Relay Hechanism 320 

The Session relay mechanism enables the passing of information from 
the original http session held by the portal server to the back end http 
session created by the portlet application's http client. This mechanism 
uses the following infrastructiure: 

Cookie Table 305 & Cookie Lookup Key 

Cookie table 305, (a user session information table) is the main 
entity for mapping the portal server cookies to the backend web 
application session cookies. The mapping relationship between the cookie 
of the http requests to the portal server and the cookie of the portlfet 
application http client to one given web application is one to one. 
However, A given portlet application http client can make http requests to 



wo 2004/031986 



'CT/GB2003/004244 



18 

different web applications with each web application maintaining 
independent sessions. With that regard, the mapping between the portal 
server session cookie and that of the backend web applications can be one- 
to many (due to multiple backend web application servers) . 

Figure 13 depicts this mapping, in which a number of items eure 
illustrated: 

RQl: cookie from the http request of a user agent (browser) to the 
portal server 

RQA: cookie from the http request of the portlet http application 
client to the web application A 

RQB: cookie from the http request of the portlet http application 
client to the web application B 

The Portlet Application Http client 209 uses this table to look up 
the matching cookie to the backend web application running on the backend 
web appilication server 210. . - 

♦ 

The existence of this cookie mapping tcdsle 305 enables the automatic 
expiration of a backend web application session when the portal sexrv^r 
session expires. 

Cookie Iiookup Key 

The portlet application http client 209 is created per portlet 
application. The cookie lookup key is stored in the portal application 
session object which is accessible to all the portlets within the same 
portlet application. This cookie lookup key is responsible for matching 
the http session of the portal server with the http session of the back 
end application. 

The use of the cookie loolcup key allows all portlets in a given 
portlet application who Bhax& the same Http Client key to retrieve and 
forward the correct set of backend web application information for the 
currently logged in user such that all the portlets in the same portlet 
application work in synchronization to update the backend web application 
being used. The effect is that the end user sees a unified view of the 
backend web application through multiple portlets. 
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Sortlet Request Parameter Map 

The Portlet Request Parameter Hap 308 is in a memory object stored 

in the shared application session data store which is created per portlet, 
per portal server session. It is used to store all request parameters from 
an incoming user request to a particular portlet. 

A. 2. Dysamio Content Ssrnohronisatlon o£ Porfclets 
A. 2.1 Qynaxnlo context Sefinltioa template 

Figure 5 illustrates portal integration with a backend web 
application. Reference to Figure 5 will be useful for the following: 

The Dynamic context Definition teniplate 503 defines the following 
for each Dynamic Context Group: 

the context and its type (in our previous example, it is the 
Account ID) . . . • - 

the master portlet who can. change the value of the. context 
defined 

the slave portlet (s) who get notified when the defined context 
is changed 

the slave portlet (s) registered response (or action) upon 
notification of the context change 

optionally defines the refresh sequence of the slave portlets 
(master always get refreshed first within a given group) 

One Dynamic Context Definition Template 503 can contain one or many 
Dynamic Context Group (s) . But each Dynamic Context Group can only have 
one master portlet 
one defined context 
one or more than one slave portlets 

Notes: a given portlet can peirticipate in more than one Dynamic Context 
Groups with different roles in each group. 

A. 2. 2 pynamic Context Portlets Groaplag Generation Tool 

This tool 501 reads in the Dynamic Context Definition Tenplate 503 
and generates Dynamic Context Master Portlet and Slave Portlets for all 
Dynamic Context groups according to the definition specified by updating 
the portlet deployment descriptors 502 correspondingly. 
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A. 2. 3 Qynamia Coateiit Group 

A dynamic context group Is a subset of portleta that share the same 
context and are grouped under one dynamic context group. A given portlet 
can belong to more than one dynamic context group. 

The Dynamic context group definition document instance 504 is used 
to define the dynamic context of a particuleu: dynamic context group) . 

Dynamic Context Master portlet 

Dynamic Context Master Portlet is responsible for 

detecting the context state change 

notifying all slave portlets on the context state change 
Dvnamic Context Slave txartletfs) 
Dynamic Context Slave portlets do the following: 



Dvnamic Context Models 

There are two types of Dynamic Context models that can be used for 
associating portlets with each other: 

A.2.4 VbB Byna xnodel 

In the Sync model, depicted in Figure 14, the master portlet 101 
informs the slaves 1701-1703 about the state change of the context of the 
Dynamic context roaster portlet. All slaves will perform actions based on a 
previously defined response to sync up with the master's context state 
change. 

Sync model diagram 

A. 2. 5 The CShainlng model 



pulling for context change as notified by the master portlet 
performs the registered action directed towards the 
corresponding back end application upon notification of 
context change 



In the chaining model, indicated in Figure 1, the change of state in 
Master A 101 results in the response action of Slave A 102, Slave A is 
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also the Master portlet B, which leads to the change of state in context 
B, resulting in the context change response of Slave B 103, slave B is 
also the master portlet of <3ynaniic context group C, resulting in the 
action response of Slave C. 

A. 2. 6 Portlet TranseMitioa Manager: 

h Sequence Aware Portal Aggregation Engine Extension Referring to 
Figure 15, the portlet transaction manager 1802 is the consjonent 
responsible for managing the ixintime refresh sequencing of the portlets 
including the creation of portlet requests, responses, and sessions. 

1 . The first portlet to be refreshed for any portlet application is 
defined as that portlet which is refreshed first among all the portlets 
for a given user. There is no existing mechanism to define the refreshing 
sequence of portlets within a given page. 

Thus, we need some logic which can identify the master portlet 
dynamically at runtime. In the present invention we use a simple 
scratchboard where each portlet makes a msLrk every time it is refreshed, 
the first time a portlet makes a meork on this scratchboard it knows that 
it is the first or master portlet. The next portlet that makes a mark on 
this list can already see that other portlet has made a mark on it and 
knows that it is not the master portlet, etc. The next time the portal 
page is refreshed, the. first portlet that makes a double mark on this list 
becomes the master portlet. The master portlet then, reinitializes this 
list by removing the marks of all the other portlets and also one of its 
doiJsle marks for the next request. This algorithm allows us to detect the 
master portlet dynamically every time a request comes in from the 
portlets' portal server. 

After the first portlet is refreshed the transaction manager takes 
over to refresh the other portlets in the sequence as predefined in the. 
master and slave portlet mapping of the dynamic context group. 

2. Sequence sorter: The sequence sorter module 1804 is used to sort 
the portlets in their refresh sequence order.. It used the portlet 
deployment descriptor to identify the refresh order of each portlet and 
then sorts them out for the request dispatching engine. 



3* Sequence Aware Request Diepatohing Engine Extension: This engine 
1805 is used to dispatch recjuests to the portlets and over-rides the 
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portal aggregation engine, its job is to construct the appropriate portlet 
request and response objects, as well as the portlet session for all the 
portlets in the commerce portal application. It is then used by the 
transaction manager to actually refresh the portlets. 

6. Transaction Hanagex Caching nnit: The transaction manager caching 
unit 1806 is used by the transaction manager 1802 to cache the responses 
produced by the portlets as they eure refreshed by the request dispatching 
engine. This is necessary as when the portal aggregation engine now 
requests for a portlet refresh, these cached responses are sent back to it 
by the transaction manager. This avoids the problem of double refresh per 
incoming portal request. 

A. 3. Rule Based and Role Based Aggregation 

Figure 11 illustrates a rule based dynamic aggregation con^onent 
structure map of a preferred embodiment of this invention. A description 
of the components of the illustrated embodiment and their operation ' 
.. follow: 

Portal Resource Translation UOdale 

The portal resource translation module 1015 is responsible for 
translating the set of Portal resources including: portlets, pages and 
page groups into a form that can be parsed and processed by the external 
rules engine 1022. 

Rules Database 

The rules database 1001 holds business manager defined rules for the 
portal aggregation engine 1006. 

User Resource Translation Ubdnle 

The user resource translation module 1013 is responsible for 
translating user resources and the various user properties into a form 
that can be peirsed and worked upon by the external rules engine. 

Pluggable Rules Engine 

The rules engine 1022 is an external, pluggable rules engine {in 
this embodiment of the invention) , such as the websphere™ personalization 
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engine, that is used for dynamic rule parsing and execution. The engine's 
execution produces the set of portal resources that the user should see 
based on the business rules defined by the business user and the user 
properties of the current user. 

5 

Portal Roles Based Personalization Engine 

The Portal roles based personalization engine 1008 is a roles based 
resource selection module that is used for extracting the list of portal 
10 resources a user is allowed to access and the list of portal resources the 

user is not allowed to access based on the user's organization membership. 

The roles based engine 1008 first looks at the user's organization 
by accessing the roles database 1007. Once the user's organization has 

15 been determined, his role is assumed to BE the same as the role of that 

organization. After this the roles based personalization engine 1008 
extracts the list of resources that have been defined as accessible and - 
inaccessible for this organization by the business user. Once this list 
has been determined IT is forwarded by this module to the portal 

20 aggregation engine's aggregated resource translation subsystem for further 

processing. 

* - 

Boles DB 

25 The Roles DB 1007 holds the organization data for the portal server. . 

It holds information about organization membership for various users and 
also the list of portal resovirces that members of an organization can and 
ccin not access based on their roles. 

30 Portal Aggregation Engine aggregated Resource Translation Subsystem 

This module 1004 is responsible for creating the master list of 
portal resources that the current user is allowed to see (this includes 
portlets, pages, and page groups) based on the output of the rules and 
35 roles based personalization engines. This module is also an adapter- for 

the actual portal aggregation engine. Its job is to not only create this 
master list but also to translate it into a form that can then be accessed 
by the actual portal aggregation engine for creating the final web site 
for the end user. 
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Part B: Operational Deeeriptlon 

B.l Portal euid Web iVpplication Integration Enabling Description 
B.1.1 Overall Integration Structure & Flow Diagrams 

Figures 2, 3, and 4, depict respectively: web application 
integration with a portal; an integration structural diagram; and an 
integration flow diagram. 

B.1.2 Detailed Deaaription 

Referring to Figure 2, when a backend web application is integrated 
with portal server, the backend web application 221 receives requests from 
the portal server 201 via portlets. The backend V7eb application 221 sends 
responses back to the portlet making the request. 

■ The response from the web application 221 is rendered via portlets 
of the portal server 201 to a user accessing the portlet. 

With the implementation of the Portal Application HTTP client 209 
multiple requests and responses to the backend web application are - 
perceived by the back end web application as cohesive sessions. The Portal 
Application Http client 209 is used to open Http communication connections 
to the backend web application 221. The backend w^ application requires 
the Portal Application Http client 209 to provide session support, cookie 
handling cUid Single Sign On (SSO) capabilities. With the Portal 
Application HTTP client 209 in place, the portlets can effectively 
communicate with web application. All the portlets in a portlet 
application (such as portlet application 205) need to have access to one 
portlet application session object 211 of the back-end application 221, 
that means that Portal Application Http client 209 must be shared by all 
the portlets within the same portal application. 

To maikB such sharing possible we have determined that a imif ied 
session object that can be shared by all portlets in a given portal 
application is needed. To provide such an object the invention herein • 
provides a Portlet Application Session object 208. The Portlet Application 
session object 208 is an object that is created by the commerce portlet ■ 
application. The portlet application session object 208 is accessible by 
all portlets in a given portlet application (such as portlets 204, 205, 
206 in portlet application 1, 207) . Without the portlet application 
session object, 208, imiltiple portlets in a given portal application will 
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all have independent user sessions and will not be able to share session 
related information. 

The Portlet Application Http client 209 is stored in the Portlet 
Application Session 208, making it possible to share it among portlets in 
the same portlet application. Without this portlet application session 
object it would not be possible for the portlets to conmunicate with a 
single web application session on the baclcend. 

All the data that is stored in the Portal Application Session object 
208 represents Portal Application Session context and exists per user per 
portal application. 

Since the Portlet Application http client 209 holds all session 
information for the back-end web application 221, it Is used as a base for 
the Session Relay mechanism 320 depicted in fig. 3. 

Session relaying allows session information to be relayed that is 
specific to the whole portal server 201 (such as leuiguage information, 
user agent information, etc) to the session information of the back-end 
web application 221. That means that the back-end web application 221 is 
able to deliver the data representation that conforms to all the 
reopiirements contained in the original request sent to the portal server 
by a user. 

For example, if the user accesses the portal using a WAP (wireless 
application protocol) enabled mobile device, with default language locale 
set to 'French' then The original http recpiest to the portal server 201 
will have ITS langriage parameter set to "French" and user-agent field of 
the HTTP header set to "WAP". The Session Relay mechanism 320 relays this 
information to the web-application 221 and the web application returns .a 
response in French that is suitable for display on the user's mobile 
device in French. If the Session Relaying were absent the web-application 
would return the information in the default-language (for example English) 
suited for the default device (for example an internet Browser) . In that 
case the user would not be able to see the retrieved data as it would be 
incompatible with the user's mobile device. 

Reference will be made to elements in the structural diagram Figure 
3 while process steps of Figure 4 will be indicated by emamerate steps. 
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Step 401, the user interacts with portlets on a web portal, for 
instance by using a computer ntouse to cliclc on a link or object displayed 
in a portlet on the user's web browser . Each portlet has its ovm portlet 
session 310 (portlet session is a piece of prior art) . As part of the 
user interaction, a remote request 306 is being made to be backend web 
application 307. 

2. Step 403, in order to pass all the parameters in the portlet session 
correctly to the backend web application each portlet request's parameter 
list is saved in the Portlet Request Parameter Map (#8) 308. These 
parameters are passed to the remote back end recjuest. 

3. Step 404, the commerce portlet uses a http client key 301 to 
determine if there is already an existing Portlet Application Session 
Object 208 and Portlet Application Http Client 303 by accessing portlet . 
application data store #4, 302. step 405, If one is not found, a new one 
will be created for all the portlets within the same portlet application. 
(Step 407, If one is found, the existing one will be used instead.) 

4. Step 406, each user credential from the original portlet session is 
saved in the cookie table 305. . ' 

5. Step 408, the user credentials from the cookie table 305 and the 
parameters prerviously saved in the portlet request psirameter map 308 are 
used to construct a new http request to the backend web application. 

6. Step 409, the call to remote web application is made 307.. 

7. Step 410, the remote web application 307 returns a response to the 
call for the portlet to display. 

B.2 pyaamic ContesEt Synchronization of Portlets 
B.2.1 Development Tina Description 

Referring to Figure 5 which depicts a structural diagram of portal 
integration with a backend web application, it may be seen that a portal 
developer can make use of the Dynamic Context Portlet Grouping Tool 501 to 
create each new Dynamic Group Definition Instance 504 . This instance is a 
grouping of associate portlets and defines which portlets are slaves and 
which portlet is the master of those slaves. The required elements of the 
Dynamic Group Definition ARB specified in the Dynamic Context Group 
Definition Template 503. 
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User uses the same tool 501 to update an existing Dynamic Context 
Group Definition. 

After the user has provided the latest dynamic context group 
definition, the Dynamic Context Portlet Grouping Tool 501 updates the 
appropriate portlet application deployment descriptors 502 to reflect the 
relationships defined in the group. 

Referring to Figure 6, a flow chart representing portal integration 
the steps of the above process may be more clearly visualized: 

When a user wants to create (608) or update (609) a dynamic context 
group, the user can enploy the grouping tool 501 (Fig. 5) . 

601, the (dynamic context grouping tool prompts for user input based 
on what is specified in the dynamic context group definition teniplate 503, 
or in the case of updating the dynamic context grouping tool reads in an 
existing dynamic context group instance, validating it with the definition 
template 503 . • , 

603, the user specifies the required information to define or update 
a dynamic context group. 

605, the dynamic context group instance 504 is generated. 

606, the deployment descriptor of all related portlets are updated. 

Dynamic Context Grouping 

Figure 7 illustrates dynaniic context for portlets. Dynamic group • 
701 is coirprised of master portlet 704, slave portlet 705, and slave 
portlet 707. 

Group 703 is conprised of master portlet 705, slave portlet 706, and 
slave portlet 707. 

Dynamic group 702 is ccaiqprised of master portlet 704 and slave " 
portlet 708. 

If the data that is represented by portlets in a Portlet Application 
is synchronized at the back-end application level, then the portlets 
deliver a coordinated view of the data just by retrieving that data from 
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the web application. However, not all portlet Interactions result in the 
changes at the backend web ^plication. Dynamic context serves as the 
synchronization *at the glass ' . It is most effective when a change in 
context requires a different query. For exan5)le, selecting a different 
account from the account list requires displaying of invoice information 
being refreshed with the account selected. 

In prior art systems Portlets were normally independent of each 
another. This invention provides method and apparatus to map the relations 
of portlets with each other and articulate their dependency on each other 
at portlet application d^loyment and configuration time. The portlets 
themselves do not need to be changed. 

The dependency relationships among portlets can be defined in a 
Dynamic Context Relationship Template 503 in which the master and slave 
relationships eure defined. 

The Dynamic Context Relationship Ten^slate 503 is preferably encoded 
as an XML data representation that defines the following: 

the subset of portlets that - constitute a dynamic context group 

the master laortlet of a dynamic context group 

the slave (s^ portlet of this dynamic context group 

the slave action that the slave (s) have to perform upon 

context state changes 

the context that all constituents of this dynamic context 
group share 

An exan^le of a Dynamic Context Group definition instance follows: 

<DynamicContextGroup> 

<DynamicContextGroupName>OrderRelatedPortletGroup 

</DynamicContextGroupName> 

<DynamicContextMasterPortlet> 

Orderltems 
</DynamicContextMasterPortlet> 
<DynamicContext>itemName 
</DynamicContext> 
<DynamicContextSlavePortlet> 



<DynamicContextSlavePortletName>UPSTracking 

</Dyna[nicContextSlavePortletName> 

<SlavePortletAction> 



http : / / invent orvserver . com/inStock/ 
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</SlavePortletAction> 
</DynamicContextSlavePortlet> 
</DynainlcContextGro\:v> 

<DynaiaicContextGroup> 

<DyneunicContext6xoupNaffle>StockInventoryPortletGroup 

</Dy]iainlcContextGb:oupNcme> 

<DynamicContextMasterPortlet> 

InStocklnventory 
</DynamicContextMasterPortlet> 
<DynamicContext>itemSKUnuniber 
</DynajnicContext> 
<DynainicContextSlavePortlet> 

<DynainicContextSlavePortletName>OrderedItems 

</I}vnaniicContextSlavePortletNaine> 

<SlavePortletAction> 

http://iryse3rver.com/lastOrderied/ 

</SlavePortletAction> 
</DynainicContextSlavePortlet> 
</DyiiaadcContextGroup> ^ ^ 

The dynamic context group Definition Instances note: one dynamic 
context group definition is one instance. However, multiple dynamic 
context group definitions can be consolidated into one file to define 
multiple instances above defines two portlet sets in a portlet application 
consisting of 3 portlets. 

In the first dynamic context group, the dynamic context shared 
between the portlets is itemName, the portlet named Orderedltems serves as 
Dynamic context Master portlet and portlets UPSTracking and 
InStocklnventory serve as the Dynamic context Slave portlets. 

In the second dynamic context group, the dynamic context shared 
between the portlets is itemSkulTuniber, the portlet named InStocklnventory 
seirves as Dynamic context Master portlet and portlet Orderedltems euid 
serves as the Dynamic context Slave portlets. 

Each Qynamic context Hester portlet observes a user HTTP request and 
looks for the dynamic context. If the dynamic context is found in the 
request, the dynamic context portlet sends a dynamic context (which is the 
name and value pair parameter in the http request) to the Slave portlets. 



wo 2004/031986 



PCT/GB2003/004244 



30 

For exaitqole if Orderedltems portlet receives an HTTP request with 
attribute itenlName set to '^PentiumlV it sends the dynamic context to the 
portlets UPSTracking and InStocklnventory notifying them that context 
itemName with value *PentiumlV' was now set in the c^amic context. 

Each Dynamic context Slave portlet listens to the master's 
notification to all slave portlets of the same dynamic context group. Upon 

receiving the master's notification, the corresponding slave action is 
invoked by adding the dynamic context to the action URL as defined in the 
dynamic context group definition instance under attribute 
^SlavePortletAction' . 

For example if inStocklnvoatory portlet receives the dynamic context 
from Orderltems portlet with dynamic context type "iteo^Name" and value 
*PentiumIV'' it will retrieve the data from the 

ht tp ! / / inventorvserver . com/ inS tock/ i teniName=Pentii3mIV url. 

Coding for an example of a Dynamic Context Group Definition Tenplate 
follows : • ' 

<xsd: schema 

xmlns :xsd=''http: / /www.w3 . org/2 001/XMLSchema" 

xmlns : cep= 

°http: //www. ibm. com/WebsphereCoramerceEnabledPortal/DynamicContextGroupDef i 
nitionSchema " > 

<annotation> 

<doc\mientation xml:lang=''en"> 

Schema for Websphere Commerce Enabled Portal Dynandc Context Group 
Definition 

Copyright 2002 IBM Corporation 
<documentation> 
< /annotation> 

<!— Dynamic Context Group Instance — > 
<xsd: element name=°DynamicContextGroup" 

type= "DynamicContextGroupDef initionTen5)late'' , 

minOccurs= ' 1 ' /> 

< '-Dynamic Context Group Definition Template Schema _ 

<xsd: complexType name="DynamicContextGrovqs>Def initionTeir(plate"> 



wo 2004/031986 ^CT/GB2003/004244 



31 



<xsd: sequence> 

<xsd: element name»"DynaiaicConkextGroupNaina'' types'xsd: string* /> 
<xsd : element name= 'PynamlcContextlllasterPortlet ' t:ype='' PortletName' l> 
<!- only one dynamic context per dynamic context grou© -> 
<xsd: element names' D3/namicContezt'' types'ContextParameter" 
maxOccur s= ' 1 " / > 

<xsd: element name^'DynamicContextSlavePortlet'' typea'SlavePortlet' 

minOccurs= " 1 " /> 

</xsd: sequenc6> 
</xsd: coinplexType> 

<xsd:coinplexType names" SlavePortlet"> 
<xsd ; sequence> 

<xsd: element name=°DynamicContextSlavePortlet° type=° PortletName" /> 
<xsd:element name='Sla'v<eSortletAction'' types'xsd: string" /> 
<xsd:element names' SlaveSortletRefreshPriority'' type='x8d: decimal', 

■ minOccSrs=" 0 ' /> 

<! - -master's context is in the slave action url i£ slave param map 
is absent — > 

<xsd: element names' SlaveParaitiMapToContext" type=°ContextParameter' 

minOccurs= " 0 ' /> 

</xsd : sequence> 
</xsd : complexTVpe> 

<X8d : simpleType name= " PortletName" > 

<xsd:string> 
</xsd: 8iii^leType> 

<!— name of the parameter in master's request izrl — > 
<xsd : sinpleType name= " ContextParameter " > 

<XEd:string> 
</xsd: simpleType> 

</xsd:schema> 
B.2.2 Bna Time 

This section will best understood by referring to Figure 8: Portlet 
implication Initialization For Dynamic Context As Specified In The 
Definition Instance; and Figure 9: Dynamic Context Portlet Group Rvm Time 
Flow. 
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There are two key component to handle Runtime aspects of the Dynamic 
Context : 

1) DynamicContextActionListener (904) (Portlet Action Listener) - it 
listens for the dynamic context change In the Master portlet. Master 
portlet in every dynamic Context Portlet Group has 
DynamicContextActionListener attached to it. 

2) DynamicContextMessageListener (906) (Portlet Message Listener) — 
is the Message Listener listens for the notification from the Master of 
the group where specific Dynamic Context is defined. Every Slave portlet 
in the Dynamic Context Portlets Group has a DynamicContextMessageListener 
attached to it. 

Step-fay-step desoription o£ the xun-time flow: 

At portlet initialization time (Fig 8: 801), all master portlets 
will add the defined dynamic context based on the portlet descriptor (802, 
805) to the master portlet 's action listener (806). For all slave- 
portlets; the dynamic context type; the action url; the parameter mapping 
and the refresh sequence, will be retrieved from the portlet descriptor 
(802, 809) and add to the slave's portlet message listener (810). ' 

1) The user interaction with the Dynamic Context Portlet Group 
Master portlet results in the change of the Dynamic Context (901) . 

2) Master's Portlet DynamicContextActionListener detects the user's 
action (902) . 

3) DynamicContextActionListener sets the name/value pair 
corresponding to the Dynamic Context in the requests object of the Master 
Portlet (904) . 

4) Master Portlet gets the value of the Dynamic Context and notifies 
all the slave portlets within the same dynamic portlet group about it 
(905). 

5) DynamicContextMessageListener associated with the Slave portlet 
for the given Master receives the notification (the value of the dynamic 
context) (906) , 

6) DynamicContextMessageListener sets the value of the 
DynamicContext in the portlet request object of the Slave portlet. (907) . 

7) The Slave portlet gets the value of the dynamic context (1008)-. 

8) The Slave Portlet modifies action defined for the given Slave 
Portlet if the mapping between context and some parameter was specified 
(1009) . 
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9) If the mapping was not specified, the name/value pair of the 
dynamic context is added to the Slave's Portlet action. 

10) Slave Portlet performs the Action as defined in the dynainlc 
context groiip instance definition (1011, 1012) . 

B.3 Rale Based Role Based Qyxiamla Aggregation 

A number of figures will be referred to in this section including: 
Figure 10: Role Based Dynamic Aggregation Component Structure Map; Figure 
11: Rule Based Dynamic Aggregation Component Structure Map; and. Figure 
12: Rule Based Dynamic Aggregation Flow Chart. 

The role and rules based dynamic aggregation con^jonents for the 
portlet server are based around the rules and roles databases and the 
concept of content groups for each role and rule. 

The content groups' for the rules are kept in the Rules DB con^jonent 
1001 shown in Figure 10. Similarly the roles content groups are defined in 
the Roles DB component 1007 shown in Figure 10. Each content group 
consists of a set of portal server resources that a user who has been 
evaluated to fall under .the purview of that particular role or rule should 
have access to. 

Another major con^onent in this scheme is the Pluggable Rules Engine 
1022. l^e task of this engine is to read in the translated user properties 
and decide dynamically at runtime the set of users who qualify for 
membership of a certain predefined user group based on these user 
properties. Also this engine maps the set of these dynamic user groups to 
the set of content groups that have been defined in the roles and rules 
DB. Preferably the Pluggable Rules Engine has a GUI to manage these tasks. 
The screen shot depicted in Figure 16 illustrates how we use the WebSphere 
Personalization Server Engine to manage these tasks. 

For exanis>le, Figure 16 illustrates how we define a dynamic group 
called "MaleTeen' and assigns all male users of ages between 16-19 to this 
group . 

As shown in Figure 17, which depicts all users who are dynamically 
evaluated to be male teenagers based on their properties will now have the 
"maleteenaction' command executed for them which would instruct the 
dynamic rules and roles based portal aggregation engine 1022 to select 
content resource for the male teen group from the Roles DB 1007. 
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At development time it is the task o£ a business manager to assign a 
set of portal resources such as: pages, portlets etc. to a specific 
content group in the Roles and Rules DB. UhLs is currently done by using 
SQL scripts that directly load the Rules and Roles DB. 

B.3.1 Rule Based Role Based Dynamic Aggregation Run Tiste Bnabling 
Deseription 

At runtime the first commarid to execute for a portal user is the 
wrapper command for the rules based engine. This command is actually a 
proxy that starts the evaluation of user's properties by the actual 
pluggable rules engine. 

In the next step the rules engine reads in the user's properties 
from his stored profile, by utilizing the user resource translation module 
to tramslate them into a form that can be understood by it. 

Figure 18 illustrates the creation of a new action called 
"MaleTeenAction" which selects all the portal resources that have been ' 
defined in the content group called 'maleteengrp" in the rules DB. 

Figure 17 illustrates creation of a dynamic aggregation nodule 
command instructing the aggregation module to select the contents of the 
'^maleteengrp" for all the users who fall under the purview of the 
previously created rule for. classifying •MaleTeens" based on dynamic user 
properties. 

Figure 17 illustrates how a given business rule (e.g. business rule 
in defining what constitutes a maleteen group) takes effect (e.g. 
maleTeenAction) in determining what content to aggregate for a given user, 
with a certain user properties, falls under such classification. 

After reading in the user properties the pluggable rules engine 
evaltiates the dynamic group membership of this user based on the rules 
defined for the various dynamic groups as shown in Figure 18. 

Once the set of dynamic groups for this user has been ascertained 
the rules engine selects the appropriate portal content for this user by 
executing the content select ion actions defined for this dynamic group as 
shown in Figure 18. These actions upon execution return the set of portal 
resources from the content groups defined for them in the Rules DB. 
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The next execution step is the evaluation of the roles assigned to 
this user by the roles engine. The roles engine uses the organization 
membership (extracted from the user profile properties) to extract the set 
of content resources for this user's role from the Roles DB. These 
resources are then added to the already existing list of rules based 
portal resources created in the previous set. 

This list is then forwarded to the dynamic Portal Aggregation Engine 
for execution. The dynamic portal aggregation engine then selects the 
portal resources identified by this list to set up the default portal view 
for this current user. 



Summary 

15 1. Common Backend Web Application Integration iinplementation 

With the Portlet Application Http Client and Portlet Application 
Session, it is now possible to have a common bacJcend web application" 
. integration model. This can be used to enable multiple portlets within the 
same portlet application to communicate with the same web application 
backend. 



This implementation of the invention makes it possible to: 

25 l»ve native portlet integration without launching separate 

browsers, and without requiring multiple proapts for user id and password 
to access the same backend web application; 

ii . make multiple requests and receive responses to/from the backend 
application with session management. 



Simple Common system leading to simple tooling 



The instant invention, provides an easy and quick method to 
integrate portlet applications with an existing web application operating 
35 on a backend server; with merely requiring the specification of the url of 

the pertinent backend web application in the deployment descriptor of the 
portlet application. With this, it is now possible to build tooling to 
take care of the commonality tasks of the integration. 



40 



3. Portlets Within The Portlet Application Share Common Session and 
Session Data 
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The iicplementation of a portlet application session object makes it 
possible for portlets of the same portlet application to share common data 
among themselves that are \inique within a portlet application, while at 
the same time being different from that of the original http session of 
the portal server. This facilitates the sharing of data unique among the 
portlets within the same portlet application. 

4. Portal Session and Back End Session Sharing Common Session Data 

The session relay implementation makes possible the sharing of 
common session data between a portal server and its backend web 
application. This enables the backend VJeb application to receive 
information from the portal server, enabling business logic of the web 
application to eacploit this information passed from the portal server. 

For exantple: if the current portlet state is to display the 
makimized view of the portlet, the backend web application can receive" 
this piece of information and take advantage of this by' sending back 
detailed business information, in contrast to the normal view of a 
portlet, in which case the backend web application would just send a 
summary version of the information. 

5. Cohesive Back End Web Application Session Distinct From The Portal 
Server with the portlet application session, portlet application session 
object, portlet http client, and the session relay mechanism A back end 
web application can now preserve its own session distinct from that of the 
portal server, but still share the same cookie with that of the portal 
server. The backend web application can now operate Independently and 
correctly, perceiving portlet requests from various portlets in a portal, 
as one virtual client, enabling a cohesive session with the backend web 
application. 

6. Single Sign On Across Portal Server and Back End Web Application 

The session relay embodiment provides single sign-on capability such 
that the user, once logged on to a portal server, is not required to 
resubmit user credentials to log on to the pertinent back end w^ 
application. This is enabled by means of a cookie table- with one to one 
mapping between the http session to the portal and the http session from 
the portlet http client to the backend web application. 
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7. Back End Web Application Behavior Synchronized With That o£ the Portal 
Server 

The session relay embodiment enables enabling seamless integration 
by synchronizing the behavior of a backend web application by relaying the 
session information from the portal session to the session of the back end 
web application. 

The following are some exan^les: 

The language and locale setting in a portal server can now be passed 
to its backend web application so that the backend application can now 
compose a response message based on the locale ■«- language setting of the 
portal server. 

Another example is that session expiry information from the portal 

server can now be passed to the backend web appli^'tioh session so that 
the backend web application session can now be timed out at the same time 
that the portal session times out. The backend web application can now be 
responsive to the portal state and events as r^elayed from the portal 
server. 

8. Synchronized Content Within The Same Portal Page 

Cynamic Context Portlet Grouping allows collaboration among portlets 
within the same dynamic context group to achieve business process and 
information integration and synchronization. 

Each portlet is allowed to participate in multiple Dynamic Context 
Groups. This provides a very open and simple programming model for portal 
administrator to group portlets into dynamic context portlet groups. 

The single structvire of Dynamic Context definition enables simple 
tooling to be built for automatic generation of Dynamic Context Master and 
Slave portlets for each grouping. 

Dynamic Context Definition iirplementatlon. Dynamic Context Group, 
master portlet and slave portlet implementation {including the slave 
tasks, slave context map) assist in providing adveuitages of the invention. 
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9. Ability To Define Refresh Sequence of Portlets 

The transaction manager provides the capability of defining a 
refresh sequence of portlets for the first time. The ability to define 
refresh sequence of portlets enables proper ins>lementation of sequential 
business logic using the porteLl / portlet architecture. The transaction 
i&anager; resource sorter; the caching of responses assist in. providing 
advantages of the invention. 

10. Rule Based and Role Based Aggregation 

Pine level portal personalization can only be achieved at present by 
dynamic aggregation. This is distinctly different from the prior art 
iirplementation of regular web applications in which there is no formal . 
concept of i>ortlete, pages or page groups applied in accordance with the 
instant invention. Fine level personalization will become more and more 
iiti>ortant as the portal market tak^s off and user requirementis for fine 
level cainpaign teirgeting etc. come in. . 

The embodiments of the invention provide a number of advantages ' 
which are listed below: 

1. The level of personalization that can be achieved by our approach is' 
much finer grained than. Portlet administration facilities provided by 
portal server today. The portlet administration facilities available today 
is by nature manual configuration. Once configured, it is static and does 
not change at run time. The invention here provides a dynamic capabilities 
to render portal resources based on rule. 

2. since the portal aggregation module is a dynamic entity, tying of 
rules and roles engines directly to it lets us achieve real-time dynamic 
aggregation capabilities without any human intervention. 

3. Personalization of coarse grained portal resources such as pages and 
page groups lets us perform dynamic layout. 

4. Much more effective campaigns, contracts etc. can be set up. This is 
of significant in^ortance to both e-Commerce retail and B2B organizations. 



5. the invention allows a much higher degree. of personalization than 
regular content personalization. For exan^le, we can actually disable 
entire sections of a webpage based on rules. This can't be done by regular 
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personalization. Pvirther, dynamic aggregation doesn't aff^ly to the domain 
of regular personalization which is content, not resoiirce related. 



